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SERVER/ INFORMATION COMMUNICATION TERMINAL, PRODUCT SALE 
MANAGEMENT METHOD, AND STORAGE MEDIUM AND PROGRAM 
TRANSMISSION APPARATUS THEREFOR 

5 BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

The present invention relates to a retail sales 
10 management system for use when products are sold via a 
communication network. 

2 . Discussion of Related Art 

15 Electronic commerce, involving the retail sales of 

products and the contracting out of services using 
communication networks, such as the Internet, has become a 
popular and wide spread addition to the retail sales 
business field. An intending purchaser, when availing 

20 himself or herself of the conveniences afforded by- 

electronic commerce, generally selects a desired product, 
or a service, by referring to products for sale, or 
services to be provided, that are listed on a computer 
screen, enters his or her name, address and telephone 

25 number, along with a payment method, and transmits these 

data to a retailer. This is all that is required of the 
purchaser; all other procedures associated with a purchase 
are handled by the retailer. 
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The price for a product or the charge for a service is 
generally set by a retailer. At this time, the retail 
price is normally determined by adding a profit margin to 
the actual expenses involved in the manufacture of a 
5 product, or in the provision of a service. Further, when 

determining a price, the popularity a product enjoys among 
users, and user product evaluations may be taken into 
account . 

There are retailing methods, such as auction sales, 

10 where buyers take the initiative in setting prices. In 
such a case, however, since the buyers compete with each 
other and bid up the price of a product, the final price 
paid may far exceed that which most consumers would regard 
as appropriate. And since an auction sale is more 

15 appropriate when the number of intending purchasers exceeds 

the available supply of a product, it is not suitable for 
general trading. 

According to one method whereby the retail price of a 
product is dynamically established, for a product such as a 

20 computer program, the employment frequency (the number of 

activations, or the employment period) is recorded and 
measured, and when a predetermined value is reached, the 
payment of a charge is requested. According to another 
method, when a specific time has elapsed following the 

25 start of a sale, the retail prices of some subject products 

are reduced. However, these retailing methods do not 
immediately and directly reflect an evaluation such as is 
acquired when a product has been tested on the market and 
has been compared with other, similar products. 

30 During the exchange of data across a communication 

network, user evaluations of content to be provided may be 
fed back to an intending purchaser. For example, the 
number of times the content was accessed, or a user 
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evaluation may be supplied as a reference item to 
facilitate the selection of content. Or, the content may- 
be ranked in accordance with its evaluation or employment 
frequency, and thereafter presented to an intending 
5 purchaser. 

However, content evaluation is merely provided as 
reference matter to be considered when a choice is made, 
and is not used as a basis for the setting of a price for a 
product (content) . 

10 As is described above, according to the conventional 

retail sales method, when a retailer sets a price for a 
product or a charge for a service, a value attributable the 
popularity of the product or the service with users, and 
how they evaluate it may be added to the price. However, 

15 when the popularity of a product or service or the user 

evaluation of it fluctuates over time, a great deal of 
labor must be devoted to immediately, and frequently, 
changing the retail price to reflect marketing realities. 
However, if a price is set each time there is a 

20 variation in the popularity or in the user evaluation of a 
product or service, a lower price can be set for an 
unpopular product or service to increase its marketing 
competitiveness, or a higher price can be set for a popular 
product or service to increase the net profit. 

25 Further, conventionally, when a retailer sets a retail 

price while taking into account the popularity or the 
evaluation of a product or a service, only the current 
popularity or evaluation are taken into consideration when 
the price is selected. However, if along with an altered 

30 retail price information were provided concerning trends 

affecting price changes (e.g., how the price will 
subsequently be changed) , such information would assist a 
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user in appropriately timing the purchase of a product or 
the selection of a service. 

As is described above, according to the conventional 
method for dynamically setting the retail price of a 
5 product, the price of a frequently employed product is 
increased and the price of a less frequently employed 
product is reduced. But the conventional method can not 
flexibly assign a new retail price consonant with a change 
in the popularity or in the overall user evaluation of a 

10 product or a service. 

It is, therefore, one object of the present invention 
to provide a retail sales management system that, consonant 
with the level of popularity or the user evaluation of a 
product or service, dynamically sets a retail price for a 

15 product or a charge for a service. 

Summary of the Invention 

To achieve the above object, according to the present 
20 invention, a server for managing the retail sales of a 

product across a communication network comprises: retail 
sales state management means for managing the retail sales 
state of the product; price setting means for dynamically 
setting the price of the product in accordance with rules 
25 and the retail sales state of the product and in accordance 

with the actual retail sales status of the product when 
managed by the retail sales state management means; and 
product information provision means for, upon the receipt 
of an information request via the communication network, 
30 furnishing a request transmission source with the 

information concerning the product and the price of the 
product, set by the price setting means at the time the 
information request is received. 
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According to the present invention, a product is any 
item targeted for business trading (sales) across a 
communication network. Therefore, in addition to prices 
for general goods and digital content, the present 
5 invention can be applied for the dynamical setting of a 

charge for a service. 

Further, according to the present invention, a server 
may also be provided that does not include the product 
information provision means and that dynamically sets 
10 retail prices consonant with the actual retail sales states 
of products . 

The server further comprises: price trend information 
provision means for generating, in accordance with the 
actual retail sales state of the product, information 

15 concerning trends affecting the changes of the price of the 

product, and for furnishing the information to the 
information request transmission source. 

This configuration is preferable because an intending 
purchaser of a product can refer to the information 

20 concerning trends affecting the changes of the price of the 

subject product, and can acquire an appropriate timing for 
the purchase of the product . 

The information concerning the trends affecting the 
changes of the price of the product can be arbitrarily set, 

25 using content based on the number of products sold, such as 

"how much the price will be increased after how many more 
products are sold", content based on a time element, such 
as "how much the price will be reduced at what time", or 
content based on a rank provided in accordance with the 

30 popularity or the user evaluation of a product, such as 

"how much the price will be increased (or reduced) when the 
rank is incremented (decremented) by one" . 

JP9 -2000- 0085 -JP1 (8728-516) 5 




Specifically, a method for setting a price in 
accordance with the number of products sold can be employed 
to increase the profit provided by a product that is 
selling well and for providing a competitive price provided 
5 by a product that is not selling well. For example, the 
price setting means can set a price for the product by 
using rules, based on the retail sales state of the 
product, according to which the price is increased as the 
number of product units sold rises or decreased as the 

10 number of product units sold falls. 

Furthermore, according to the present invention, a 
server for charging for and providing digital content via a 
communication network comprises: sales state management 
means, for managing the sales state of the digital content; 

15 price setting means, for dynamically changing a charge for 

accessing the digital content in accordance with rules and 
the sales state of the digital content and in accordance 
with the sales state of the digital content, which is 
managed by the sales state management means; and 

20 information provision means for presenting to an 

information request transmission source, upon the receipt 
of an information request via the communication network, 
information concerning the digital content and the charge 
for accessing the digital content that is set by the price 

25 setting means at the time the information request is 

received. 

A server can be provided that does not include the 
information provision means and that dynamically sets the 
access charge in accordance with the actual sales state of 
30 the digital content. 

The server further comprises: price trend information 
provision means, for generating, in accordance with the 
sales state of the digital content, information concerning 

JP9-2 000-0085-JP1 (872 8-516) 6 




trends affecting the changing of the charge for accessing 
the digital content and for furnishing the information to 
the information request transmission source. 

This configuration is preferable because a user who 
5 accesses and downloads the digital content can refer to the 

information concerning the trends affecting the price of 
the subject product, and can acquire an appropriate timing 
for accessing the digital content. 

As well as for a general product, information 

10 concerning trends associated with the changing of an access 
charge, such as the contents based on an access count, the 
contents based on a time element, or the contents based on 
a rank awarded in accordance with the popularity or the 
user evaluation of a product, can be arbitrarily set. 

15 The price setting means sets the charge for accessing 

the digital content in accordance with rules and the sales 
state of the digital content and according to which the 
charge for an access is increased when the number of 
accesses of the digital content rises or is reduced when 

20 the number of accesses falls. 

The price setting means sets the charge for accessing 
the digital content in accordance with rules, which is 
based on the sales state of the digital content, according 
to which the charge for an access is increased when the 

25 rank awarded the digital content, which is consonant with 

the popularity or the evaluation of the digital content, is 
incremented, or the charge for an access is reduced when 
the rank awarded the digital content is decremented. 

According to the present invention, an information 

30 communication terminal is provided, for accessing a product 

retail sales management server across a communication 
network and for purchasing a product offered by the server, 
whereby an information request is issued to the server in 
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order to obtain information concerning the product and the 
price of the product; whereby the information concerning 
the product and the price of the product, and information 
concerning trends affecting the changes of the price are 
5 received after the server has accepted the information 

request; and whereby, when a user has examined the 
information, as needed, and has determined to purchase the 
product, a purchase request to that effect is transmitted 
to the server. 

10 Further, according to the present invention, a product 

retail sales management method, for managing the retail 
sales of a product in accordance with a purchase request 
that is issued, via a communication network, by a server 
connected thereto, comprises the steps of: managing the 

15 retail sales state of the product; dynamically setting the 
price of the product in accordance with rules and the 
retail sales state of the product and in accordance with 
the actual retail sales status of the product; and 
furnishing information concerning the product upon the 

20 receipt of an information request via the communication 

network, and furnishing the price set for the product at 
the time the information request is accepted. 
The product retail sales management method further 
comprises, after the step of furnishing the price of the 

25 product, a step of accepting a purchase request for the 

product that is issued after the information concerning the 
product and the price of the product have been provided. 

The product retail sales management method of the 
invention further comprises the steps of: generating, upon 

30 receipt of the information request, information concerning 

trends affecting the changes of the price of the product in 
accordance with the retail sales state of the product. At 
the step of furnishing the information concerning the 
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product and the price of the product, the information 
concerning the trends affecting the changes of the price of 
the product can also be furnished. 

According to the present invention, a storage medium 
5 can be provided on which reading means of a computer stores 

a computer-readable program that permits the computer to 
perform the processes that correspond to the steps of the 
product retail sales management method. 

In addition, a program transmission apparatus can be 
10 provided that comprises: storage means for storing the 
program; and transmission means for reading, from the 
storage means, and transmitting the program. 

This configuration is preferable because a computer 
that executes the program can perform product retail sales 
15 management, including dynamically setting the price of a 

product in accordance with its retail sales state of the 
product . 

Brief Description of the Drawings; 

20 

Fig. 1 is a diagram for explaining the general 
configuration of a retail sales management system according 
to the embodiment . 

Fig. 2 is a diagram for explaining the structure of a 
25 product retail sales management server according to the 

embodiment . 

Fig. 3 is a diagram showing an example structure for 
an initial setup table used for the embodiment. 

Fig. 4 is a diagram showing an example structure for a 
30 price determination policy table used for the embodiment. 

Fig. 5 is a diagram showing an example structure for a 
current price table used for the embodiment . 
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Fig. 6 is a diagram showing an example structure for a 
price trend table used for the embodiment. 

Fig. 7 is a diagram showing an example structure for a 
retail sales history table used for the embodiment. 
5 Fig. 8 is a flowchart for explaining the operation of 

an acceptance module according to the embodiment. 

Fig. 9 is a flowchart for explaining the operation of 
a retail sales management module according to the 
embodiment . 

10 Fig. 10 is a flowchart for explaining the operation of 

a price update module according to the embodiment . 

Fig. 11 is a flowchart for explaining the operation of 
a price trend update module according to the embodiment. 
Fig. 12 is a diagram showing an example input screen 
15 used for the embodiment. 

Fig. 13 is a diagram showing the state of the input 
screen after a predetermined time has elapsed since the 
state shown in Fig. 12. 

Fig. 14 is a diagram showing the initial states of the 
20 respective tables for an example operation according to the 

embodiment . 

Fig. 15 is a diagram showing tables in which the 
states of the contents in Fig. 14 have been changed. 

Fig. 16 is a diagram showing tables in which the 
25 states of the contents in Figs. 14 and 15 have been 

changed. 

Fig. 17 is a diagram showing the initial states of the 
respective tables for another example operation according 
to the embodiment. 
30 Fig. 18 is a diagram showing tables in which the 

states of the contents in Fig. 17 have been changed. 
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Fig. 19 is a diagram showing tables in which the 
states of the contents in Figs. 17 and 18 have been 
changed . 



5 Detailed Description of Preferred Embodiments 

Preferred embodiments of the present invention will 
now be described in detail while referring to the 
accompanying drawings . 

10 Fig. 1 is a diagram for explaining the general 

configuration of a retail sales management system according 
to the embodiment. In this embodiment, the retail sales 
management system can be used to provide various products 
and services; however, to simplify the explanation, general 

15 goods and services are collectively described as products, 

and the retail sales of digital content, such as music, is 
especially employed as an example. Further, the Internet 
is employed as a communication network. 

In Fig. 1, the retail sales management system for this 

20 embodiment is carried out by a product retail sales 

management server 10 for the retail sales of products 
across the Internet. The product retail sales management 
server 10 receives a request from a user terminal 30, a 
client, returns an input screen file as an interface, and 

25 accepts from the user terminal 3 0 the entry of data 

concerning the purchase of a product . 

In Fig. 1, when the user terminal 3 0 issues a product 
information request (101) to the product retail sales 
management server 10, the product retail sales management 

30 server 10 returns, to the user terminal 30, an input screen 

file (102) in which is written information concerning the 
product for sale, and the user terminal 3 0 displays an 
input screen based on the input screen file (102) that is 
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received from the product retail sales management server 
10. On the input screen, information concerning the 
product for sale and the current retail price for the 
product are displayed. 
5 Then, the user designates a desired product by 

referring to the input screen, enters necessary 
information, and uses the user terminal 3 0 to transmit a 
purchase determination command (103) to the product retail 
sales management server 10. Upon the receipt of the 

10 command, the product retail sales management server 10 

returns, to the user terminal 30, a notification (104) 
confirming the reception of the purchase procedures. 

The product purchase processing is the same as the 
electronic commerce processing used to purchase an ordinary 

15 product via the Internet. In this embodiment, it should be 

noted that, since the retail price of the product is 
dynamically set, when the product information is 
transmitted as the input screen file (102) the retail price 
of the product is defined as the current price. Therefore, 

20 when the product is to be purchased after a specific time 
has elapsed since product information was furnished, the 
processing for the provision of the latest retail price of 
the product can be added. That is, the user terminal 3 0 
transmits a product purchase request (105) to the product 

25 retail sales management server 10, and receives from the 

product retail sales management server 10 the latest retail 
price (106) . If a predetermined time has elapsed since the 
product retail sales management server 10 received the 
purchase determination command (103), the server 10, 

30 instead of accepting the purchase procedures, may return 

the latest retail price (106) . 

In this arrangement, the functions of the product 
retail sales management server 10 can be performed by a web 
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server, and the input screen is prepared as a web page. 
Then, when at the user terminal 3 0 data is entered in the 
web page, the product purchase procedures are accepted. 

Further, in this case, the user terminal 30 uses a web 
5 browser to display the web page. 

Fig. 2 is a diagram for explaining the configuration 
of the product retail sales management server 10. 
In Fig. 2, an acceptance module 11 accepts a product 
information request (101) from the user terminal 30. A 

10 retail sales management module 12 manages the history of 

the retail sales of the product. A price update module 13 
manages the retail price of the product. And a price trend 
update module 14 manages the trends associated with the 
changing of the retail price of the product. 

15 A database 2 0 is used to manage the product and its 

sale, and an initial setup table 21 , a price determination 
policy table 22, a current price table 23, a price trend 
table 24, a retail sales history table 25, and a ranking 
table 26 are stored in the database 20. 

20 Fig. 3 is a diagram showing an example structure for 

the initial setup table 21. 

Various information for determining the price of a 
product is stored in the initial setup table 21. In the 
example in Fig. 3, a product ID, a dependency element for 

25 determining the retail price, the lowest price, the highest 

price and the currency unit are stored in the initial setup 
table 21. The dependency element is used to determine the 
price of a product and a change in the price. The number 
of sales in Fig. 3 indicates that the price will be changed 

30 when a predetermined number of product sales have been 

recorded. That is, since digital content, such as music or 
video data, is downloaded once every time it is sold, the 
price is changed in accordance with the sales count. For a 
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product or a service other than digital content, the price 
can be changed in accordance with the number of units that 
have been sold or the number of times the service has been 
provided. In addition to the sales count in Fig. 3, the 
5 dependency element can be the retail sale frequency, which 

indicates the number of retail sales (units) processed in a 
specific period of time, or a ranking based on an arbitrary 
concept, such as a retail sales ranking or a popularity 
ranking based on predetermined data. Since for the sale of 

10 music, there is a web site that provides rankings 

representative of the popularity of musical pieces, ranking 
information obtained by tying up with the site can be 
employed as the dependency element. 

The lowest price and the highest price are set so that 

15 the price of the product will not fall below or rise above 

a specific value. When a certain product is especially 
popular and purchase requests are concentrated on that 
product, if the number of purchases is set as the 
dependency element, the price of the product will increase 

20 endlessly. However, when the price has increased until it 

is too high to be appropriate for the product, the number 
of purchase requests will fall, and this is not an 
acceptable condition for either the seller and the buyers. 
On the other hand, when the popularity of a specific 

25 product is low and the no trading history has been 

accumulated for it, a price whereat there is neither a loss 
nor a profit must be set based on the manufacturing cost of 
the pertinent product. Therefore, a reasonable price range 
should be determined for the product. However, these data 

30 are not requisite, and one or both of the lowest and the 

highest prices may not be set as desired by the seller. 
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Since the entry for the currency unit is set while 
taking into account the convenience it offers for trading, 
this is an arbitrary setting. 

Fig. 4 is a diagram showing an example structure for 
5 the price determination policy table 22. 

In the price determination policy table 22, the policy 
for determining the price of a product is set for a 
corresponding dependency element in the initial setup table 
21. For example, when the number of retail sales is set as 

10 the dependency element in the initial setup table 21 , a 
retail sales count dependency policy was set, such as 
"increase the price by 10 yen when there have been twenty 
sales of the product", or "reduce the price by 10 yen when 
there have been no sales of the product for 12 0 minutes". 

15 Similarly, when the ranking is set as the dependency 

element of the initial setup table 21, a ranking dependency 
policy is established, such as "increase the price by 10 
yen when the rank is incremented by one", or "reduce the 
price by 10 yen when the rank is decremented by one". 

20 Further, when retail sales frequency is set as the 

dependency element for the initial setup table 21, a retail 
sales frequency dependency policy is entered, such as 
"increase the price by 10 yen when the retail sales 
frequency (the number of retail sales (units) handled in a 

25 predetermined period) is increased by 10%" or "reduce the 

price by 10 yen when the retail sales frequency is reduced 
by 20%". It should be noted that the parameters (the 
count, the ranking, the retail sales frequency, etc.) in 
the policy described above, and the unit for the price 

30 change (10 yen) can be arbitrarily established. 

Fig. 5 is a diagram showing an example arrangement for 
the current price table 23. 
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The product ID and the current price of the product 
are stored in the current price table 23. In addition, the 
currency unit for the price is stored as needed, e.g., when 
a purchase request originating in a foreign country is 
5 accepted via the Internet. 

Fig. 6 is a diagram showing an example structure for 
the price trend table 24. 

A condition for a next price change is stored in the 
price trend table 24 consonant with the dependency element 

10 in the initial setup table 21. For example, the number of 

retail sales is set as the dependency element in the 
initial setup table 21, and a condition such as "increase 
the price of the product after five more sales (Rest_C 5)" 
or "last time the product was sold (Last Access_C) " is set 

15 as a parameter until the price is changed. Further, when 

the retail sales frequency is set as the dependency element 
in the initial setup table 21, a condition such as 
"increase the price of the product when it is sold five or 
more times a day (Freq__C 5)" is set as a parameter until 

20 the price is changed. In addition, the time condition 

can be set as a parameter, and a condition such as 
"maintain the current price until 12:59 in the afternoon 
(Next_T 12:59 PM) " can be designated. The numerical value 
for the count, the frequency and the time for each 

25 condition can be arbitrarily set. 

Fig. 7 is a diagram showing an example arrangement for 
the retail sales history table 25. 

The retail sales time and the price of the product at 
that time are stored in the retail sales history table 25. 

30 The total number of retail sales of the product is also 

managed in this table. And in addition, ID information for 
purchasers of the product may be stored in order to provide 
after sale service. 
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When the ranking information is set as the dependency 
element in the initial setup table 21, a rank (the retail 
sales count rank or popularity rank) corresponding to the 
dependency element is stored in the ranking table 26. In 
5 this embodiment, a site for obtaining the aggregate for the 

ranking may be provided for the product retail sales 
management server 10 that provides a product retail 
service, and unique ranking may be determined. Or, the 
information for ranking performed by another web site is 
10 obtained, depending on a product, and may be stored in the 

ranking table 26. When the product is music or video, the 
information is obtained from the site established to 
provide rankings for the popularity of music pieces or 

hi 

Q films, so that the price of the product can be set based on 

Y£ 15 more general ranking information. 

ij The operations of the individual modules will now be 

i /J described. First, the operation of the acceptance module 

in 11 will be explained. 

Fig. 8 is a flowchart for explaining the processing 

'-■ IS* 

20 performed by the acceptance module 11 in Fig. 2. 
ij When the acceptance module 11 receives a product 

; =3 information request (see 101 in Fig. 1) from the user 

terminal 30 (step 801) , the acceptance module 11 examines 
the current price table 23 to obtain the current retail 

25 price of the requested product (step 802) . Then, the 

acceptance module 11 inquires of the price trend update 
module 14 the trends associated with the changing of the 
price of the product (step 803) . The acceptance module 11 
prepares the input screen for the purchase of the product 

30 in accordance with the current retail price obtained at 

step 802 and the information concerning the price change 
trends received from the price trend update module 14 at 
step 803. And the file for the input screen (see 102 in 
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Fig. 1) is transmitted to the user terminal 30 (step 804) . 
A detailed description of the input screen will be given 
later. 

During this processing, the acceptance module 11 
examines the price trend table 24 to directly obtain 
information concerning the price change trends, but also 
inquires of the price trend update module 14 the trends 
associated with the changing of the price. This is done 
because since the information for the trends associated 
with the changing of the product price varies in accordance 
with the retail sales state of the product and the elapsed 
time, the user terminal 3 0 should be provided the latest 
information. 

When the user terminal 3 0 receives the data file for 
the input screen, it then displays the input screen. 
Thereafter, to purchase a desired product, a user enters 
data on the input screen displayed by the user terminal 30, 
and uses the user terminal 30 to transmits a purchase 
determination command (see 103 in Fig. 1) . At this time, 
since at the least, a specific time will have elapsed 
between the time the input screen file was received and the 
time the purchase determination command was issued, the 
retail price of the product may have changed since the 
input screen file was received. In this case, when the 
product retail sales management server 10 accepts the 
purchase determination command (corresponding to step 801) , 
before finally accepting the purchase request, the server 
10 may perform the processes at steps. 802 to 804 and 
transmit the latest retail price to the user terminal 30 
(see 106 in Fig. 1) . 

A script may also be displayed in the input screen 
file transmitted to the user terminal 3 0 in order to 
request the periodic transmission of the latest price and 
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the price change trends, so that for updating, the price 
and the price change trends are periodically transmitted by 
the product retail sales management server 10. 

The processing performed by the retail sales 
5 management module 12 will now be described. 

Fig. 9 is a flowchart for explaining the processing 
performed by the retail sales management module 12. 

The retail sales management module 12 monitors the 
operation of the acceptance module 11. When the retail 
10 sales management module 12 detects the receipt by the 

acceptance module 11 of the product purchase determination 
command and the acceptance of the purchase procedures (step 
901) , the retail sales management module 12 updates the 
retail sales history table 25 (step 902) . Then, in order 
15 to determine whether the price should be changed for this 

retail sale, the retail sales management module 12 calls up 
the price update module 13 and shifts the program control 
to it. Thereafter, the processing is terminated (step 
903) . 

20 The operation of the price update module 13 will now 

be described. 

The price update module 13 operates periodically, or 
in accordance with a call by the retail sales management 
module 12, and updates the current price table 23. 

25 Fig. 10 is a flowchart for explaining the processing 

performed by the price update module 13 . 

The price update module 13 is activated when it is 
called up by the retail sales management module 12, or when 
a predetermined start time is reached (step 1001) . Then, a 

30 policy PO is obtained from the price determination policy 
table 22, and a change condition C, which is effective 
until the retail price of the product is changed, is 
acquired from the price trend table 24 (step 1002) . The 
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information required to determine whether the current price 
table 23 must be updated is also acquired in accordance 
with the policy PO and the change condition C (step 1003) . 
The information required for the determination differs, 
5 depending on the definition of the policy PO. 

When the policy PO for changing the price in 
accordance with the number of units sold is defined, 
information concerning the number of product units sold 
must be obtained from the retail sales history table 25 in 

10 order to ascertain how many units have been sold. Further, 

when the policy PO according to which the price is changed 
as time elapses is defined, the current time must be 
obtained from the system. 

In this manner, required information is acquired in 

15 accordance with the contents of the policy PO. When all 

information that it seems may be used for the determination 
has been acquired, only necessary information is employed 
in accordance with the contents of the policy PO. 

Then, the obtained information and the policy PO are 

20 employed to determine whether the current price table 23 

should be updated (step 1004) . Then, when the policy PO 
definition is that the price must be changed in accordance 
with the number of retail sales unit, and the number of 
retail sales unit at which the price must be changed is 

25 reached, it is ascertained that the current price table 23 
must be updated. 

When it is ascertained that an update of the current 
price table 23 is necessary, thereafter, a new price based 
on the policy PO is calculated, and the price of the 

30 product in the current price table 23 is updated (steps 

1005 and 1006) . 

When the current price table 23 has been updated in 
this manner, or when an update is not required, the price 
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trend update module 14 is called up and program control is 
shifted thereto. The processing is thereafter terminated 
(step 1007) . When the current price table 23 is updated 
and the price of the product is changed, the price trend 
5 table 24 must be changed in accordance with the new price. 

Even if the current price table 23 need not be updated, a 
condition that is effective until the price has been 
changed may be altered when the product has been sold or 
when a predetermined time has elapsed. Therefore, the 

10 price trend update module 14 determines whether the 

condition is changed, and if necessary, updates the price 
trend table 24. 

The operation of the price trend update module 14 will 
now be described. 

15 Fig. 11 is a flowchart for explaining the processing 

performed by the price trend update module 14 . 

The price trend update module 14 is activated upon the 
receipt of the inquiry from the acceptance module 11 (see 
step 803 in Fig. 8) or in accordance with the call issued 

20 by the price update module 13 (see step 1007 in Fig. 10) 
(step 1101) . Then, the price trend update module 14 
obtains, from the price determination policy table 22, the 
policy PO for determining the retail price of the product, 
and acquires from the price trend table 24 the change 

25 condition C that is effective until the retail price of the 

product is changed (step 1102) . 

In accordance with the policy PO and the change 
condition C, the price trend update module 14 also obtains 
the information needed to determine whether the price trend 

30 table 24 should be updated (step 1103) . The information 

required for the determination differs, depending on the 
definition provided by the policy PO. 
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When the policy PO for changing the price in 
accordance with the number of retail sale units is defined, 
the condition "change the price after several more units 
have been sold" is changed each time the product is sold. 
5 Therefore, information concerning the number of retail 

sales units must be acquired from the retail sales history 
table 25. Further, when the policy PO as defined is for 
the changing of the price as time elapses, the condition 
"change the price several minutes (or several hours or 

10 several days) from now", or the condition "change the price 

at a specific hour (or on a specific date) " is changed to 
reflect each predetermined time. Therefore, the time 
information must be obtained from the system. 

In this manner, required information is acquired in 

15 accordance with the contents of the policy PO. Further, 

all the information that it seems may be used for the 
determination may be obtained, but only necessary 
information may be employed in consonance with the contents 
of the policy PO. 

20 The obtained information is employed to determine 

whether the updating of the price trend table 24 is 
required (step 1104) . That is, a check is performed to 
determine whether the information obtained at step 1102 
satisfies the change condition C obtained from the price 

25 trend table 24. When the information does not satisfy the 

condition, e.g., if the policy PO for changing the price in 
accordance with the number of retail sales units is defined 
and the number of retail sales units is 0, the processing 
is terminated without updating the price trend table 24 

30 (step 1105) . 

When the information obtained at step 1102 satisfies 
the change condition C acquired from the price trend table 
24, e.g., when the policy PO establishes that a price in 
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accordance with the number of units purchased and when the 
number of purchases is equal to or greater than one, the 
price trend table 24 is updated in accordance with the 
policy PO (steps 1105 and 1106) . 
5 When the price trend update module 14 is activated 

upon the receipt of the inquiry from the acceptance module 
11, the price trend update module 14 transmits, to the 
acceptance module 11, a response stating whether the price 
trend table 24 has been changed and including the results 

10 obtained by changing the price trend table 24 (step 1107) . 

As is described above, since the price trend update 
module 14 is operated in the same way as is the price 
update module 13, and is also activated when the acceptance 
module 11 has received a request for product information, 

15 the latest information can always be stored in the price 

trend table 24 . 

In this embodiment, the price trend update module 14 
has been activated not only upon the receipt of the inquiry 
from the acceptance module 11, but also by being called by 

20 the price update module 13. However, the price trend 

update module 14 may be operated separately from the price 
update module 13. For example, when the policy for 
changing the price of the product as time elapses is 
defined in the price determination policy table 22, 

25 information concerning the trend associated with the 

changing of the price is varied, as needed. 

Therefore, it is preferable that, in order to update 
the price trend table 24, the price trend update module 14 
be operated more frequently than the price update module 

30 13. 

Fig. 12 is a diagram showing an example input screen 
displayed by the user terminal 30. In an input screen 40, 
music provided as digital content is defined as a product, 
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and the price is to be changed in accordance with the 
number of purchases (the number of downloads) . 

As is described above, when a product information 
request is issued by the user terminal 3 0 to the product 
5 retail sales management server 10, the acceptance module 11 

of the product retail sales management server 10 prepares 
the input screen 40, and transmits the file for the input 
screen 40 to the user terminal 30. The user terminal 30 
then uses a browser to display the input screen 40, and 

10 waits for the input of data by a user. 

In Fig. 12, the input screen 40 includes a product 
information display column 41, for displaying information 
concerning a product, a price display column 42, for 
displaying the price of the product, a price trend display 

15 column 43, for indicating the trend associated with the 

changing of the price, and a purchase button 44, for 
transmitting a purchase determination command. In the 
example in Fig. 12, music pieces 1 to 3, recorded by a 
singer A, and music pieces 1 to 3 , recorded by a singer B, 

20 are displayed as product information and are presented in 

the product information display column 41, while the prices 
of the individual music pieces are displayed in the price 
display column 42. Further, the number of purchases (the 
number of downloads) remaining until the product price is 

25 next raised is displayed in the price trend display column 
43. This value, together with a message at the bottom of 
the input screen 40, "raise the price 10 yen every 20 
downloads", represents the price change trend. That is, 
the user understands that when the number of product 

30 information downloads equals the number displayed in the 

price trend display column 43, the download count will 
reach 20 and the price of the product will be raised 10 
yen. 
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When the user selects a desired music piece (a 
product) on the input screen 4 0 and clicks on the purchase 
button 44, the purchase determination command is 
transmitted to the product retail sales management server 
5 10. Further, if needed, when the purchase button 44 is 

clicked on, a purchase procedures screen may be displayed 
and the user requested to enter his or her name and address 
and to select a payment method. When a predetermined time 
has elapsed between the time the input screen 40 was 

10 displayed and the purchase button 44 was clicked on, 

instead of the transmission of the purchase determination 
command, a message may be displayed requesting the 
provision of the latest information for the price and the 
price change trends, and the data on the input screen 40 

15 may be updated. 

Fig. 13 is a diagram showing the state of the input 
screen 4 0 when a predetermined time has elapsed since the 
state shown in Fig. 12 was acquired. 

In Fig. 13, the prices for the individual music pieces 

20 and the price change trends (information indicating the 

remaining download count before the price is raised) are 
changed. For example, it is apparent that music piece 1, 
recorded by singer A, has been downloaded 15 times, and 
that the price will be raised after another five downloads. 

25 Similarly, it is apparent that after the price of the music 

piece 2, recorded by singer A was raised five times (the 
music piece 2 was downloaded 100 (= 20 x 5) times) , the 
music piece 2 was downloaded ten more times, and its price 
will be raised to 140 yen after another ten downloads. In 

30 this manner, more profits can be obtained with a popular, 

good selling product by raising its price, and a 
competitive price can be provided for a poor selling 
product by reducing its price. 
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The input screen 4 0 shown in Fig. 12 and 13 is merely 
an example, and so long as the same data entry is 
available, the structure is not limited to the one shown. 
For example, the purchase button 44 may not be provided and 
5 the screen may be shifted to a purchase procedure screen by 

clicking on a desired music piece. Or, a script may be 
written in the input screen file, so that the price of the 
product or the price change trends can be automatically 
updated. 

10 The information presented in the product information 

display column 41 should also be appropriately displayed in 
accordance with the kind of product. For example, if the 
product is not digital content but an article, an image of 
the article or an introductory statement for the article 

15 may be provided. 

A specific operation performed for this embodiment 
will now be described. Fig. 14 is a diagram showing the 
initial state of each table prepared for a predetermined 
product. Since the price of a product is changed without 

20 depending on the rankings, the ranking table 26 is not 

present. It should be noted that in Fig. 14 the formats 
shown in Fig. 3 to 7 are not employed for the respective 
tables and that only brief listings of the contents are 
displayed. 

25 In Fig. 14, in the initial setup table 21, the number 

of units (Deal Count) of the product (Product ID 01) 
purchased is set as the dependency element (Dependency_l) . 
In the price determination policy table 22, the number of 
units (Up counter_C) that must be purchased to raise the 

30 price is set at 20, and the price rise range (Up Range_C) 
is set at 10 yen. In the current price table 23, the 
initial value of the retail price (Price) is set at 1000 
yen. In the price trend table 24, the number of remaining 
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units that must be purchased before the price rise (Rest_C) 
is initially set to 20. The retail sales history table 25 
is set to Null because the sale of the product has not yet 
begun . 

5 Assume that one purchaser bought one product (Product 

ID 01) at predetermined time (11:00). Fig. 15 is a diagram 
showing a table wherein the contents are changed by this 
purchase . 

In Fig. 15, the retail sales history table 25 records 

10 11:00 (written as T(11:00)) as the purchase time (Purchase 

Time) of the product (Product ID 01) , and records 1000 yen 
as the purchase price (Purchase Price) . Accordingly, as is 
shown in Fig. 10, the price update module 13 is operated 
and whether the current price table 23 must be updated is 

15 determined. In this example, since the number of units (Up 

Counter_C) required to raise the price in the price 
determination policy table 22 is set at 20, and the number 
of remaining units (Rest_C) before the price is raised in 
the price trend table 24 is set at 20, no price change is 

20 performed. 

The price trend update module 14 is operated and 
whether the price trend table 24 must be updated is 
determined. But since one product (Product ID 01) unit has 
been purchased, the price trend table 24 is updated, and 

25 the number of units remaining before the price is raised is 

decremented by one, to 19. 

Assume that a predetermined time has elapsed (11:30) 
and the total number of purchased product (Product ID 01) 
units has reached 20. Fig. 16 is a diagram showing a table 

30 in which the contents are accordingly changed. 

In Fig. 16, the retail sales history table 25 records 
11:30 (written as T(ll:30)) as the purchase time (Purchase 
Time) of the product (Product ID 01) , and records 1000 yen 
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as the purchase price (Purchase Price) . Accordingly, as is 
shown in Fig. 10, the price update module 13 is operated 
and whether the current price table 23 must be updated is 
determined. In this example, since the number of units 
5 purchased reaches 20, that is the number of units {Up 

Counter_C) required to raise the price in the price 
determination policy table 22, and the number of remaining 
units (Rest_C) before the price is raised in the price 
trend table 24 is reduced to 0. Thus, the current price 

10 table 23 is updated and the retail price of the product 

(Product ID 01) is changed. Since the range (Up Range_C) 
of the price rise in the Price determination policy table 
22 is 10 yen, the retail price (Price) in the current price 
table 23 is increased 10 yen to 1010 yen. Therefore, the 

15 product (Product ID 01) is thereinafter purchased at 1010 

yen. 

The price trend update module 14 is operated and 
whether the price trend table 24 need be updated is 
determined. In this example, the price trend table 24 is 

20 also updated based on the updating of the current price 

table 23. Specifically, since this occurs immediately 
after the current price table 23 is updated by the price 
update module 13 and the new retail price is obtained, the 
number of units (Up Counter_C) required to increase the 

25 price in the price determination policy table 22 is again 
set to 20. 

Another example operation for this embodiment will now 
be described. 

Fig. 17 is a diagram showing the initial states of the 
30 tables concerning a predetermined product. In this 

example, since the price of the product is changed without 
depending on its rank, the ranking table 26 is not present. 
It should be noted that in Fig. 14 the formats shown in 
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Fig. 3 to 7 are not employed for the respective tables and 
the only brief listings of the contents displayed. 

In this example, the price update module 13 and the 
price trend update module 14 are activated every ten 
5 minutes to determine whether the current price table 23 and 

the price trend table 24 must be updated. 

In Fig. 17, in the initial setup table 21, the number 
of units (Deal Count) of the product (Product ID 01) that 
are purchased is set as the dependency element 

10 (Dependency_l) . In the price determination policy table 

22, the number of units (Up counter_C) that must be 
purchased to raise the price is set at 20, and the price 
rise range (Up Range_C) is set at 10 yen. Further, in this 
example, when there have been no product (Product ID 01) 

15 purchases for a predetermined period of time, the retail 

price of the product is reduced. Thus, in the price 
determination policy 22, the time defined as the price 
reduction condition (Time Limit_C) is 7200 seconds, and the 
range of a price reduction (Down Range_C) is set at 10 yen. 

20 In the current price table 23, the initial value of 

the retail price (Price) is set at 1000 yen. In the price 
trend table 24, the number of units remaining to be 
purchased before a price rise (Rest_C) is initially set to 
20. The last access time (Last Access_C) , i.e., the time 

25 whereat the count is initially began, is set at 10:00 

(written as T(10:00)). And the retail sales history table 
25 is set to Null because the sale of the product is not 
yet begun. 

After 10:00, the product retail sales management 
30 server 10 activates the price update module 13 and the 

price trend update module 14 every 10 minutes to permit 
them to determine whether the updating of the tables is 
necessary. However, because in each case the time elapsed 
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since the price trend table 24 was last accessed (Last 
Access_C) is less than 7200 seconds, which is the price 
reduction condition in the price determination policy table 
22, neither the current price table 23 nor the price trend 
5 table 24 are updated. 

Assume that one purchaser bought one product (Product 
ID 01) at a predetermined time (11:00) . Fig. 18 is a 
diagram showing tables wherein the contents are changed by 
this purchase. 

10 In Fig. 18, the retail sales history table 25 records 

11:00 (written as T(11:00)) as the purchase time (Purchase 
Time) of the product (Product ID 01) , and records 1000 yen 
as the purchase price (Purchase Price) . Accordingly, the 
price update module 13 is operated and whether the current 

15 price table 23 must be updated is determined. In this 

example, since the number of units (Up Counter_C) required 
to raise the price in the price determination policy table 
22 is set at 20, and the number of remaining units (Rest_C) 
before the price will be raised in the price trend table 24 

20 is set at 20, no price change is performed. 

Thereafter the price trend update module 14 is 
operated and whether the price trend table 24 must be 
updated is determined. Since one product (Product ID 01) 
unit has been purchased, the price trend table 24 is 

25 updated, and the number of units remaining before the price 
is raised is decremented by one, to 19, and 11:00 
(T(11:00)) is set as the last access time (Last Access_C) . 

Assume that thereafter the product (Product ID 01) is 
not purchased for 72 00 seconds (two hours) . Then, 

30 (T (Current Time) - Last Access_C) ^ (Time Limited) 

is established, and thus, the price update module 13 and 
the price trend update module 14 update the current price 
table 23 and the price trend table 24. Fig. 19 is a 
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diagram showing the tables after the contents have been 
accordingly changed. 

In Fig. 19, first, since the range (Down Range_C) of 
the price reduction in the price determination policy table 
5 22 is 10 yen, the retail price (Price) in the current price 

table 23 is reduced by 10 yen to 990 yen. Thus, the 
product (Product ID 01) can thereafter be purchased at 990 
yen. 

Since the current price table 23 has just been updated 

10 by the price update module 13 and a new retail price has 

just been obtained, the price trend update module 14 again 
set to 20, the number of units (Up Counter_C) that are 
required to be purchased for the price in the price 
determination policy table 22 to be raised. Further, in 

15 order to count the time again, the last access time (Last 

Access_C) is set to the current time (written as T (Current 
Time) ) , i.e., 13 : 00 . 

As is described above, the retail price of the product 
can be dynamically changed in accordance with the retail 

20 sales state of the product, and an appropriate retail price 

can be set in accordance with the reaction of the market. 

As is described above, according to the present 
invention, a retail sales management system can be provided 
that dynamically sets the retail price for a product or a 

25 service in accordance with the popularity or an evaluation 

of the product or the service. 

A legend for the symbols is repeated herein for 
convenience : 

10: Product retail sales management server 
30 11: Acceptance module 

12: Retail sales management module 

13 : Price update module 

14 : Price trend update module 
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20: Database 

21: Initial setup table 

22: Price determination policy table 

23: Current price table 

24: Price trend table 

25: Retail sales history table 

26: Ranking table 

30: User terminal 

40: Input screen 



Having described embodiments of the invention it is 
noted that modifications and variations can be made by 
persons skilled in the art in light of the above teachings. 
It is therefore to be understood that changes may be made in 

15 the particular embodiments of the invention disclosed which 

are within the scope and spirit of the invention as defined 
by the appended claims. Having thus described the invention 
with the details and particularity required by the patent 
laws, what is claims and desired protected by Letters Patent 

20 is set for in the appended claims. 
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